Systems for accomplishing business transactions electronically are becoming increasingly widespread, partly because of the advent of global computer networks such as the Internet, and partly because of the evolution and maturity of public key cryptography, which enhances the security of such commerce. The application of public key cryptography to electronic commerce has been heretofore envisioned in documents such as Recommendation X.509 of the International Telecommunications Union (ITU, formerly CCITT) (hereinafter “Standard X.509”), the Digital Signature Guidelines of the American Bar Association's Information Security Committee (December 1995 edition, hereinafter “ABA Guidelines”), and statutes and regulations such as the Utah Digital Signature Act, Utah Code Ann. title 46, chapter 3 (1996) (hereinafter “Utah Act”).
The backdrop established in these and other documents addresses some problems but leaves many of them unsolved and unresolved.
2.1 Conventional Approaches to Digital Signature Certification
To use secure electronic commerce according to the conventional methods, each user has a pair of related keys, namely a private key (to be kept secret by the user) and a public key (which can be known by anyone without compromising the secrecy of the corresponding private key). Using a particular public key, an algorithm can determine whether the corresponding private key was used to sign or authenticate a given message. For example, if A wishes to send B a message, and provide B with a high degree of assurance that the message is genuinely A's, then A can digitally sign the message using A's private key, and B can thereafter verify that the message is truly A's using A's public key.
A public key is simply a value (generally a number), and has no intrinsic association with anyone, including the person whose message it is to authenticate. Widespread, commercial use of digital signatures requires reliable information associating public keys with identified persons. Messages of those identified persons can then be authenticated using the keys.
Digital signature certificates (sometimes also called public key certificates or simply certificates) meet this need. These certificates are generally issued by trusted third parties known as certification authorities (CAs) and they certify (1) that the issuing certification authority has identified the subject of the certificate (often according to specifications delineated in a certification practice statement), and (2) that a specified public key (in the certificate) corresponds to the a private key held by the subject of the certificate. A structure for public-key certificates is included in the X.509 standard cited earlier. The content of a certificate is often specified in a statute or regulation. A typical X.509 certificate has the format shown in FIG. 1.
In order to assure that a certificate's authenticity can be subsequently verified, the certification authority digitally signs the certificate when issuing it. The issuing certification authority's digital signature can itself be verified by reference to a public key (the certification authority's public key), which is associated with the certification authority in another certificate issued by a second certification authority to the first certification authority. That other certification authority's digital signature can be verifiable by a public key listed in yet another certificate, and so on along a chain of certificates until one reaches a so-called root or prime certification authority whose public key is widely and reliably distributed. For maximum assurance of the authenticity of a certificate relied upon in a transaction, the relying party must, using conventional methods, verify each certificate in the chain. An example of a certification chain is shown in FIG. 2, wherein a root certification authority issues a certificate to certification authority CA-1 which in turn certifies certification authorities CA-2 and CA-5. Certification authority CA-2 certifies CA-3 which certifies CA-4 which certifies subscriber-1. Certification authority CA-5 certifies subscriber-2.
Most legal systems treat a certificate as a representation, finding, or conclusion made pursuant to a contract between the issuing certification authority and the subscriber, i.e., the person identified in the certificate as the holder of the private key corresponding to the public key listed in the certificate. Persons other than the subscriber may rely on the certificate. The certification authority's duties in relation to those relying parties may stem from rules governing representations or false statements, rules treating the relying party as a third-party beneficiary of the contract between the certification authority and subscriber, statutes governing digital signatures, or a blend of all of the above as well as perhaps additional legal principles.
Often, a party's right to rely on a certificate is limited. In the law applicable to misrepresentations, for example, reliance is generally required to be reasonable. Further, reliance on some certificates is specified to be per se unreliable. A bright line separates certain classes of clearly unreliable certificates from all others, and a relying party relies on them at its own peril, without recourse against the issuing certification authority or subscriber for a defect in the certificate. Certificates that are per se unreliable are conventionally termed invalid, and may include any certificate which:                (1) Has, expired (i.e., the time of reliance is later than the date specified in the certificate for its expiration);        (2) Has been revoked (i.e., have been declared permanently invalid by the certification authority which issued the certificate); and        (3) Is suspended at the time of reliance (i.e. has been declared temporarily invalid by the certification authority which issued the certificate).        
In addition, a certificate which has not been accepted by its subscriber or issued by a certification authority should not be considered to have taken effect, and could, perhaps rather loosely, be considered invalid.
Suspending and/or revoking certificates are an important means of minimizing the consequences of errors by the certification authority or subscriber. Depending on applicable legal rules, a certification authority may avert further loss due to inaccuracy in the certificate by revoking it. A subscriber can revoke a certificate to prevent reliance on forged digital signatures created using a compromised, e.g., lost or stolen, private key. Certificates which become invalid by revocation are generally listed in a certificate revocation list (CRL), according to ITU X.509. Suspension, or temporary invalidation, was not contemplated in ITU X.509, and may or may not be included in the CRL. Certificates which become invalid by virtue of their age need not be listed in a CRL because each certificate contains its own expiration date.
As a practical matter, the conventional CRL-based system works as follows. Before a subscriber can create a verifiable digital signature, the signer must arrange for a certification authority to issue a certificate identifying the subscriber with the subscriber's public key. The subscriber receives back and accepts the issued certificate, and then creates digital signatures and attaches a copy of the certificate to each of them. When the other party to a transaction receives such a digital signature, the other party must check with the certification authority, generally via its on-line database, to determine whether the certificate is currently valid. If so, and if the digital signature can be verified by the public key in the certificate, the party is usually in a strong position to rely on the digital signature.
2.2 Problems with the Conventional Approaches to Digital Signature Certification
The system summarized above and envisioned in Standard X.509, the ABA Guidelines, the Utah Act, and similar documents has several deficiencies, including:                Little support for risk management: The conventional system provides very few facilities or opportunities to enable a certification authority to manage the risk of certification. The certification authority is not informed when anyone relies on a certificate that the certification authority has issued or the extent to which anyone relies on any certificate it has issued. The certification authority also has no way of monitoring outstanding certificates, ascertaining whether problems arise, evaluating which factors affect the risk of faulty certification or the scope of exposure to risk that the certification authority should prudently undertake. Furthermore, conventional systems provide few facilities to help subscribers and relying parties manage their risks, including the risk of keeping the private key secure.        Relying party is under-served: To a great extent, it is the relying party, not the subscriber, who bears the risk of fraud or forgery in the transaction. If a document is forged or is fraudulently altered, the relying party will suffer the consequences, which, according to the law of most states, is that the message is treated as void. Although the relying party has the keenest interest in the information security of the transaction, the certification authority's service contract is entirely with the subscriber. In the case of a fraud or forgery, the subscriber may even be the perpetrator. The roles of the conventional system thus set the certification authority up to deal with relatively disinterested parties or even perpetrators in problem cases, but to have no contact with the party who primarily bears the loss. This state of affairs exposes the certification authority to serious liability risks in relation to the relying party and causes the certification authority to forgo the business opportunity of serving the relying party. Rather than dealing exclusively with the subscriber, the digital signature infrastructure also needs a way of dealing with the relying party.        Cost front-loaded onto subscriber: Since the certification authority's contract is with the subscriber alone, not with the relying party, the certification authority has no alternative but to recover all costs and profit from the subscriber, even though, as previously noted, the relying party has the principal interest in the security of the signed message.        Lack of robustness: Because the conventional system fails to address risk management and the needs of relying parties, certification authorities have tended to interpret their rotes narrowly. A certification authority may, for example, promise to look by rote at an apparent driver's license, or accept at face value a notarized application for certification, without purposefully endeavoring to serve the real business need for certification, which is to assure the expectations of the parties to the transaction. This mechanical approach to certification limits the potential for CAs to add further value to electronic commerce transactions. A more robust system needs to be serviceable for certifying authorization, accreditation, legal status of a juridical entity, and credit, for example.        